-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intoroduce parameterizing rules with conditional statement #418
base: master
Are you sure you want to change the base?
Conversation
2cb042d
to
c15c765
Compare
9a48181
to
6ba14f2
Compare
6ba14f2
to
b90290f
Compare
b90290f
to
a044fe0
Compare
a044fe0
to
dd5808c
Compare
I would like to propose a new grammar in this PR. I believe that more parameterizing rules can handle more abstract rules if we can switch between rules and actions that are expanded by conditions in order to make rules common. Syntax is as follows: ``` %rule defined_rule(X, condition): /* empty */ | X { $$ = $1; } %if(condition) /* 1 */ | %if(condition) X %endif X { $$ = $1; } /* 2 */ ; %% r_true : defined_rule(number, %true) ; r_false : defined_rule(number, %false) ; ``` 1. It's like a postfix if in Ruby. If condition is false, it is equivalent to missing this line. 2. If statementIf condition is false, it is equivalent to missing RHS between `%if` and`% endif`. I believe it will solve the problem mentioned in the article below with the tight coupling with Lexer "to disable certain generation rules under certain conditions" and I would like to propose this feature to solve this problem. https://yui-knk.hatenablog.com/entry/2023/04/04/190413 We can trace the RHS to [f_args](https://github.com/ruby/ruby/blob/2f916812a9b818b432ee7c299e021ec62d4727fb/parse.y#L5523-L5575) > [args_tail](https://github.com/ruby/ruby/blob/2f916812a9b818b432ee7c299e021ec62d4727fb/parse.y#L5487-L5503) > [args_forward](https://github.com/ruby/ruby/blob/2f916812a9b818b432ee7c299e021ec62d4727fb/parse.y#L5586-L5597), where f_args is the RHS of both the lambda argument (f_larglist) and the method definition argument (f_arglist). So if we can switch between RHS and actions by passing parameters, we can break up the Lexer/Parser coupling here.
``` %rule defined_rule(X, condition): X { $$ = $1; } %if(condition) ; ```
dd5808c
to
77218fe
Compare
parser.y
Outdated
{ | ||
builder = val[2] | ||
builder.symbols << val[3] if val[3] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
builder
(is the instance of Grammar::ParameterizingRule::Rhs
) has one or zero if_clause
. Then I think it's reasonable for builder
has attribute for if_clause
than holding if_clause
on symbols
.
I agree to the feature.
Sorry for the late response. |
I would like to propose a new grammar in this PR.
I believe that more parameterizing rules can handle more abstract rules if we can switch between rules and actions that are expanded by conditions in order to make rules common.
Syntax is as follows:
It's like a postfix if in Ruby. If condition is false, it is equivalent to missing this line.
Old design
DesignDoc: https://gist.github.com/ydah/62008655a6f6c3118ab01134dc91da6f
Syntax is as follows:
%if
and% endif
.Motivation
I believe it will solve the problem mentioned in the article below with the tight coupling with Lexer "to disable certain generation rules under certain conditions" and I would like to propose this feature to solve this problem.
https://yui-knk.hatenablog.com/entry/2023/04/04/190413
We can trace the RHS to f_args > args_tail > args_forward, where f_args is the RHS of both the lambda argument (f_larglist) and the method definition argument (f_arglist).
So if we can switch between RHS and actions by passing parameters, we can break up the Lexer/Parser coupling here.